Dynomotion

Group: DynoMotion Message: 3862 From: himykabibble Date: 2/12/2012
Subject: Jogging Problems
Tom,

My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.

I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.

I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog functions.

Regards,
Ray L.
Group: DynoMotion Message: 3864 From: Tom Kerekes Date: 2/12/2012
Subject: Re: Jogging Problems
Hi Ray,
 
Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
 
Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
 
Regards
TK
 

Group: DynoMotion Message: 3869 From: himykabibble Date: 2/12/2012
Subject: Re: Jogging Problems
Tom,

OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.

Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
>  
> Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
>  
> Regards
> TK
>  
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Sunday, February 12, 2012 8:26 AM
> Subject: [DynoMotion] Jogging Problems
>
>
>  
> Tom,
>
> My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
>
> I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
>
> I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog functions.
>
> Regards,
> Ray L.
>
Group: DynoMotion Message: 3870 From: Tom Kerekes Date: 2/12/2012
Subject: Re: Jogging Problems
That is correct.  Except Rapids (G0) also use the KFLOP parameters.
TK

Group: DynoMotion Message: 3884 From: himykabibble Date: 2/13/2012
Subject: Re: Jogging Problems
Tom,

I did a capture, but it wasn't particularly helpful. I captured the MoveExp command parameters I was sending to KFlop, and they looked fine. In fact, considerably smoother than I expected. What I did find is that I had TAU set a bit low (0.08), and that the final Move() is what's really killing me. If I change the final move to a MoveExp(), I very rarely get faults. With the Move() there (and both Move and MoveExp are setting the same destination), I get very frequent faults. Again, I NEVER get faults using Jog(), no matter how hard I hammer on it.

One thing I tried was to not allow a new jog to start until the machine came fully to rest from the previous one. I've tried to do this using both CheckDone(), and CheckDoneXYZABC (which, BTW, is listed as CheckXYZ in the KMotion help....), but NEITHER will reliably tell me when the machine is stopped. Most often, they both continue to return 0, even loooooong after the machine has come to rest. The only reliable way I've found to sense the machine has stopped is to read chn->Dest, and wait until it returns the same value on successive time slices. Why do the CheckDone functions not work as I would expect?

Not allowing a new jog to start until the machine has come to rest works OK, except due to the final MoveExp, it takes about a second to determine the machine has stopped. This makes the jog response, especially in step mode, unacceptably slow.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.
>
> Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
> >  
> > Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
> >  
> > Regards
> > TK
> >  
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, February 12, 2012 8:26 AM
> > Subject: [DynoMotion] Jogging Problems
> >
> >
> >  
> > Tom,
> >
> > My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
> >
> > I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
> >
> > I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog functions.
> >
> > Regards,
> > Ray L.
> >
>
Group: DynoMotion Message: 3885 From: Tom Kerekes Date: 2/13/2012
Subject: Re: Jogging Problems
Hi Ray,
 
MoveExp does an exponential move that goes forever so CheckDone will never return true.  Other than that CheckDone should work perfectly.
 
I think I see an issue/bug when issuing a Move while a MoveExp is in progress.  There is no current command to "stop" a MoveExp short of disabling the axis which is a bit harsh.  Try adding the following command before calling Move or Jog or anything (except another MoveExp):
 
chX->pcoeff = NULL;
 
We should probably add a function called StopMoveExp() to do that.
 
Please try that to see if it makes a difference.
 
Regards
TK
 
 
Group: DynoMotion Message: 3886 From: himykabibble Date: 2/13/2012
Subject: Re: Jogging Problems
Tom,

I'll give that a shot tomorrow...

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> MoveExp does an exponential move that goes forever so CheckDone will never return true.  Other than that CheckDone should work perfectly.
>  
> I think I see an issue/bug when issuing a Move while a MoveExp is in progress.  There is no current command to "stop" a MoveExp short of disabling the axis which is a bit harsh.  Try adding the following command before calling Move or Jog or anything (except another MoveExp):
>  chX->pcoeff = NULL;
>  
> We should probably add a function called StopMoveExp() to do that.
>  
> Please try that to see if it makes a difference.
>  
> Regards
> TK
>  
>  
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 13, 2012 12:18 PM
> Subject: [DynoMotion] Re: Jogging Problems
>
>
>  
> Tom,
>
> I did a capture, but it wasn't particularly helpful. I captured the MoveExp command parameters I was sending to KFlop, and they looked fine. In fact, considerably smoother than I expected. What I did find is that I had TAU set a bit low (0.08), and that the final Move() is what's really killing me. If I change the final move to a MoveExp(), I very rarely get faults. With the Move() there (and both Move and MoveExp are setting the same destination), I get very frequent faults. Again, I NEVER get faults using Jog(), no matter how hard I hammer on it.
>
> One thing I tried was to not allow a new jog to start until the machine came fully to rest from the previous one. I've tried to do this using both CheckDone(), and CheckDoneXYZABC (which, BTW, is listed as CheckXYZ in the KMotion help....), but NEITHER will reliably tell me when the machine is stopped. Most often, they both continue to return 0, even loooooong after the machine has come to rest. The only reliable way I've found to sense the machine has stopped is to read chn->Dest, and wait until it returns the same value on successive time slices. Why do the CheckDone functions not work as I would expect?
>
> Not allowing a new jog to start until the machine has come to rest works OK, except due to the final MoveExp, it takes about a second to determine the machine has stopped. This makes the jog response, especially in step mode, unacceptably slow.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Tom,
> >
> > OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.
> >
> > Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
> > >  
> > > Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
> > >  
> > > Regards
> > > TK
> > >  
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Sunday, February 12, 2012 8:26 AM
> > > Subject: [DynoMotion] Jogging Problems
> > >
> > >
> > >  
> > > Tom,
> > >
> > > My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
> > >
> > > I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
> > >
> > > I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog functions.
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>
Group: DynoMotion Message: 3887 From: Brad Murry Date: 2/13/2012
Subject: Re: Jogging Problems

Hello Tom,

 

Would a MoveRel(0) do anything to help?

 

-Brad Murry

 

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Monday, February 13, 2012 4:55 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: Jogging Problems

 

 

Hi Ray,

 

MoveExp does an exponential move that goes forever so CheckDone will never return true.  Other than that CheckDone should work perfectly.

 

I think I see an issue/bug when issuing a Move while a MoveExp is in progress.  There is no current command to "stop" a MoveExp short of disabling the axis which is a bit harsh.  Try adding the following command before calling Move or Jog or anything (except another MoveExp):

 

chX->pcoeff = NULL;

 

We should probably add a function called StopMoveExp() to do that.

 

Please try that to see if it makes a difference.

 

Regards

TK

 

 

From: himykabibble <jagboy@...>
To: DynoMotion@yahoogroups.com
Sent: Monday, February 13, 2012 12:18 PM
Subject: [DynoMotion] Re: Jogging Problems

 

 

Tom,

I did a capture, but it wasn't particularly helpful. I captured the MoveExp command parameters I was sending to KFlop, and they looked fine. In fact, considerably smoother than I expected. What I did find is that I had TAU set a bit low (0.08), and that the final Move() is what's really killing me. If I change the final move to a MoveExp(), I very rarely get faults. With the Move() there (and both Move and MoveExp are setting the same destination), I get very frequent faults. Again, I NEVER get faults using Jog(), no matter how hard I hammer on it.

One thing I tried was to not allow a new jog to start until the machine came fully to rest from the previous one. I've tried to do this using both CheckDone(), and CheckDoneXYZABC (which, BTW, is listed as CheckXYZ in the KMotion help....), but NEITHER will reliably tell me when the machine is stopped. Most often, they both continue to return 0, even loooooong after the machine has come to rest. The only reliable way I've found to sense the machine has stopped is to read chn->Dest, and wait until it returns the same value on successive time slices. Why do the CheckDone functions not work as I would expect?

Not allowing a new jog to start until the machine has come to rest works OK, except due to the final MoveExp, it takes about a second to determine the machine has stopped. This makes the jog response, especially in step mode, unacceptably slow.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.
>
> Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
> >  
> > Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
> >  
> > Regards
> > TK
> >  
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Sunday, February 12, 2012 8:26 AM
> > Subject: [DynoMotion] Jogging Problems
> >
> >
> >  
> > Tom,
> >
> > My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
> >
> > I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
> >
> > I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog functions.
> >
> > Regards,
> > Ray L.
> >
>

 
Group: DynoMotion Message: 3888 From: himykabibble Date: 2/13/2012
Subject: Re: Jogging Problems
Tom,

I got a chance to try this, and it made a HUGE difference.... in the wrong direction. It's FAR worse now, and even Jog() will cause faults on almost every move. Nearly always when it stops, and much less often when it starts, there is a very violent move that makes a loud "bang", and the servo faults. If I comment out the new line, this goes away, and Jog() works well again.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Tom,
>
> I'll give that a shot tomorrow...
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > MoveExp does an exponential move that goes forever so CheckDone will never return true.  Other than that CheckDone should work perfectly.
> >  
> > I think I see an issue/bug when issuing a Move while a MoveExp is in progress.  There is no current command to "stop" a MoveExp short of disabling the axis which is a bit harsh.  Try adding the following command before calling Move or Jog or anything (except another MoveExp):
> >  chX->pcoeff = NULL;
> >  
> > We should probably add a function called StopMoveExp() to do that.
> >  
> > Please try that to see if it makes a difference.
> >  
> > Regards
> > TK
> >  
> >  
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, February 13, 2012 12:18 PM
> > Subject: [DynoMotion] Re: Jogging Problems
> >
> >
> >  
> > Tom,
> >
> > I did a capture, but it wasn't particularly helpful. I captured the MoveExp command parameters I was sending to KFlop, and they looked fine. In fact, considerably smoother than I expected. What I did find is that I had TAU set a bit low (0.08), and that the final Move() is what's really killing me. If I change the final move to a MoveExp(), I very rarely get faults. With the Move() there (and both Move and MoveExp are setting the same destination), I get very frequent faults. Again, I NEVER get faults using Jog(), no matter how hard I hammer on it.
> >
> > One thing I tried was to not allow a new jog to start until the machine came fully to rest from the previous one. I've tried to do this using both CheckDone(), and CheckDoneXYZABC (which, BTW, is listed as CheckXYZ in the KMotion help....), but NEITHER will reliably tell me when the machine is stopped. Most often, they both continue to return 0, even loooooong after the machine has come to rest. The only reliable way I've found to sense the machine has stopped is to read chn->Dest, and wait until it returns the same value on successive time slices. Why do the CheckDone functions not work as I would expect?
> >
> > Not allowing a new jog to start until the machine has come to rest works OK, except due to the final MoveExp, it takes about a second to determine the machine has stopped. This makes the jog response, especially in step mode, unacceptably slow.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Tom,
> > >
> > > OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.
> > >
> > > Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
> > > >  
> > > > Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Sunday, February 12, 2012 8:26 AM
> > > > Subject: [DynoMotion] Jogging Problems
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
> > > >
> > > > I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
> > > >
> > > > I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog functions.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>
Group: DynoMotion Message: 3889 From: Tom Kerekes Date: 2/13/2012
Subject: Re: Jogging Problems
Hi Ray,
 
Well when are you doing it?  Maybe I should have been more clear.  You can't issue that command while in motion as it will cause a dead stop and a fault.  Only do it (one time) after a MoveExp has virtually finished moving before issuing a Jog or Move.
 
Regards
TK

Group: DynoMotion Message: 3890 From: himykabibble Date: 2/13/2012
Subject: Re: Jogging Problems
Tom,

How do I know when a MoveExp has "virtually finished moving"?

What I'm really after is a way to quickly stop the axis. I don't much care WHERE it stops if it's moving at any significant velocity, though if it's moving relatively slowly, I'd like it to stop at an exact position.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> Well when are you doing it?  Maybe I should have been more clear.  You can't issue that command while in motion as it will cause a dead stop and a fault.  Only do it (one time) after a MoveExp has virtually finished moving before issuing a Jog or Move.
>  
> Regards
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 13, 2012 6:31 PM
> Subject: [DynoMotion] Re: Jogging Problems
>
>
>  
> Tom,
>
> I got a chance to try this, and it made a HUGE difference.... in the wrong direction. It's FAR worse now, and even Jog() will cause faults on almost every move. Nearly always when it stops, and much less often when it starts, there is a very violent move that makes a loud "bang", and the servo faults. If I comment out the new line, this goes away, and Jog() works well again.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > Tom,
> >
> > I'll give that a shot tomorrow...
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > >  
> > > MoveExp does an exponential move that goes forever so CheckDone will never return true.  Other than that CheckDone should work perfectly.
> > >  
> > > I think I see an issue/bug when issuing a Move while a MoveExp is in progress.  There is no current command to "stop" a MoveExp short of disabling the axis which is a bit harsh.  Try adding the following command before calling Move or Jog or anything (except another MoveExp):
> > >  chX->pcoeff = NULL;
> > >  
> > > We should probably add a function called StopMoveExp() to do that.
> > >  
> > > Please try that to see if it makes a difference.
> > >  
> > > Regards
> > > TK
> > >  
> > >  
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Monday, February 13, 2012 12:18 PM
> > > Subject: [DynoMotion] Re: Jogging Problems
> > >
> > >
> > >  
> > > Tom,
> > >
> > > I did a capture, but it wasn't particularly helpful. I captured the MoveExp command parameters I was sending to KFlop, and they looked fine. In fact, considerably smoother than I expected. What I did find is that I had TAU set a bit low (0.08), and that the final Move() is what's really killing me. If I change the final move to a MoveExp(), I very rarely get faults. With the Move() there (and both Move and MoveExp are setting the same destination), I get very frequent faults. Again, I NEVER get faults using Jog(), no matter how hard I hammer on it.
> > >
> > > One thing I tried was to not allow a new jog to start until the machine came fully to rest from the previous one. I've tried to do this using both CheckDone(), and CheckDoneXYZABC (which, BTW, is listed as CheckXYZ in the KMotion help....), but NEITHER will reliably tell me when the machine is stopped. Most often, they both continue to return 0, even loooooong after the machine has come to rest. The only reliable way I've found to sense the machine has stopped is to read chn->Dest, and wait until it returns the same value on successive time slices. Why do the CheckDone functions not work as I would expect?
> > >
> > > Not allowing a new jog to start until the machine has come to rest works OK, except due to the final MoveExp, it takes about a second to determine the machine has stopped. This makes the jog response, especially in step mode, unacceptably slow.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > >
> > > > Tom,
> > > >
> > > > OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.
> > > >
> > > > Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Ray,
> > > > >  
> > > > > Nothing specific comes to mind.  It may your system simply can't handle full Acceleration unlimited Jerk moves.  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.  This is a huge shock to the system.  Your Accelerations are pretty high.  Jogs do not do this as they limit Jerk.  G1's do this but with two differences #1 they use different settings (TP settings).  #2 they are rarely commanded at max feed rate (rapid rates).
> > > > >  
> > > > > Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.  You only need to catch one fault.
> > > > >  
> > > > > Regards
> > > > > TK
> > > > >  
> > > > >
> > > > > From: himykabibble <jagboy@>
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Sunday, February 12, 2012 8:26 AM
> > > > > Subject: [DynoMotion] Jogging Problems
> > > > >
> > > > >
> > > > >  
> > > > > Tom,
> > > > >
> > > > > My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
> > > > >
> > > > > I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
> > > > >
> > > > > I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog
> functions.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
>
Group: DynoMotion Message: 3891 From: Tom Kerekes Date: 2/14/2012
Subject: Re: Jogging Problems
Hi Ray,
 
"virtually finished moving" would be defined by you as slow enough that your system wouldn't mind coming to an abrupt stop from that point.   Probably the simplest might be some time (1 sec?) after the last MoveExp was commanded.  Or you could check the chx->Dest to be within some tolerance of the last commanded position.
 
I really don't understand exactly what you are doing or the need to switch between all these modes on the fly.  We don't currently offer a 3rd order blended move transition from a MoveExp into a Move or Jog like we do between Move->Move, Jogs->Jogs, Move->Jog, Jog->Move.  I suppose one could be added at least a 2nd order blend.  But really It seems to me the best way to come to a smooth stop when using the MoveExp is to just wait and not change the Dest anymore.
 
As I stated before we sort of have a bug where while a MoveExp is in progress (and lets assume virtually stopped - yet still being executed) and and Move or Jog is commanded then there is a small window of time while the new Move/Jog Coefficients are being installed, if a Servo Interrupt occurs, and one final MoveExp calculation is performed a garbage Dest may be computed.  So the chX->pcoeff = NULL should prevent this from ever happening as it kills any further trajectory from being computed until a new move is commanded.  Any new move will assume a motion from a stopped condition.
 
Regards
TK
 
 

Group: DynoMotion Message: 3892 From: himykabibble Date: 2/14/2012
Subject: Re: Jogging Problems
Tom,

I was able to get what I wanted by just doing away with MoveExp altogether. At a very low MPG turn rate, I just use Move to move in 0.001" increments. At any higher rate, I just use Jog() with the velocity determined by how fast you turn the MPG. Seems to work fine. By filtering the MPG pulse rate, I get a nice, smooth response, and it's easy to hold a fairly constant speed, for "manual" machining.

I may try again using MoveExp once I get a better MPG.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> "virtually finished moving" would be defined by you as slow enough that your system wouldn't mind coming to an abrupt stop from that point.   Probably the simplest might be some time (1 sec?) after the last MoveExp was commanded.  Or you could check the chx->Dest to be within some tolerance of the last commanded position.
>  
> I really don't understand exactly what you are doing or the need to switch between all these modes on the fly.  We don't currently offer a 3rd order blended move transition from a MoveExp into a Move or Jog like we do between Move->Move, Jogs->Jogs, Move->Jog, Jog->Move.  I suppose one could be added at least a 2nd order blend.  But really It seems to me the best way to come to a smooth stop when using the MoveExp is to just wait and not change the Dest anymore.
>  
> As I stated before we sort of have a bug where while a MoveExp is in progress (and lets assume virtually stopped - yet still being executed) and and Move or Jog is commanded then there is a small window of time while the new Move/Jog Coefficients are being installed, if a Servo Interrupt occurs, and one final MoveExp calculation is performed a garbage Dest may be computed.  So the chX->pcoeff = NULL should prevent this from ever happening as it kills any further trajectory from being computed until a new move is commanded.  Any new move will assume a motion from a stopped condition.
>  
> Regards
> TK
>  
>  
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, February 13, 2012 7:32 PM
> Subject: [DynoMotion] Re: Jogging Problems
>
>
>  
> Tom,
>
> How do I know when a MoveExp has "virtually finished moving"?
>
> What I'm really after is a way to quickly stop the axis. I don't much care WHERE it stops if it's moving at any significant velocity, though if it's moving relatively slowly, I'd like it to stop at an exact position.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> >  
> > Well when are you doing it?  Maybe I should have been more clear.  You can't issue that command while in motion as it will cause a dead stop and a fault.  Only do it (one time) after a MoveExp has virtually finished moving before issuing a Jog or Move.
> >  
> > Regards
> > TK
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, February 13, 2012 6:31 PM
> > Subject: [DynoMotion] Re: Jogging Problems
> >
> >
> >  
> > Tom,
> >
> > I got a chance to try this, and it made a HUGE difference.... in the wrong direction. It's FAR worse now, and even Jog() will cause faults on almost every move. Nearly always when it stops, and much less often when it starts, there is a very violent move that makes a loud "bang", and the servo faults. If I comment out the new line, this goes away, and Jog() works well again.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > >
> > > Tom,
> > >
> > > I'll give that a shot tomorrow...
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Ray,
> > > >  
> > > > MoveExp does an exponential move that goes forever so CheckDone will never return true.  Other than that CheckDone should work perfectly.
> > > >  
> > > > I think I see an issue/bug when issuing a Move while a MoveExp is in progress.  There is no current command to "stop" a MoveExp short of disabling the axis which is a bit harsh.  Try adding the following command before calling Move or Jog or anything (except another MoveExp):
> > > >  chX->pcoeff = NULL;
> > > >  
> > > > We should probably add a function called StopMoveExp() to do that.
> > > >  
> > > > Please try that to see if it makes a difference.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >  
> > > > From: himykabibble <jagboy@>
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Monday, February 13, 2012 12:18 PM
> > > > Subject: [DynoMotion] Re: Jogging Problems
> > > >
> > > >
> > > >  
> > > > Tom,
> > > >
> > > > I did a capture, but it wasn't particularly helpful. I captured the MoveExp command parameters I was sending to KFlop, and they looked fine. In fact, considerably smoother than I expected. What I did find is that I had TAU set a bit low (0.08), and that the final Move() is what's really killing me. If I change the final move to a MoveExp(), I very rarely get faults. With the Move() there (and both Move and MoveExp are setting the same destination), I get very frequent faults. Again, I NEVER get faults using Jog(), no matter how hard I hammer on it.
> > > >
> > > > One thing I tried was to not allow a new jog to start until the machine came fully to rest from the previous one. I've tried to do this using both CheckDone(), and CheckDoneXYZABC (which, BTW, is listed as CheckXYZ in the KMotion help....), but NEITHER will reliably tell me when the machine is stopped. Most often, they both continue to return 0, even loooooong after the machine has come to rest. The only reliable way I've found to sense the machine has stopped is to read chn->Dest, and wait until it returns the same value on successive time slices. Why do the CheckDone functions not work as I would expect?
> > > >
> > > > Not allowing a new jog to start until the machine has come to rest works OK, except due to the final MoveExp, it takes about a second to determine the machine has stopped. This makes the jog response, especially in step mode, unacceptably slow.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> > > > >
> > > > > Tom,
> > > > >
> > > > > OK, I'll do a capture and see what I see. When I was tuning the servos, I actually found I could set both acceleration and jerk MUCH higher with no problems - I ran accel from 25 up to 40 in/sec2, and jerk from 4E6 up to 4E12. It was really hammering the poor machine, but never faulted once.
> > > > >
> > > > > Question - If I de-tune acceleration and jerk in my init.c, but leave them set high in CoordMotion and Interpreter, will that work? Would that only impact moves programmed directly by the DSP (which is only pendant, probing and homing), and allow the Interpreter to operate as it does now?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > Hi Ray,
> > > > > > ÃÆ'‚ 
> > > > > > Nothing specific comes to mind.ÃÆ'‚  It may your system simply can't handle full Acceleration unlimited Jerk moves.ÃÆ'‚  2nd order moves are very violent - full motor torque is slammed on (or even fully reversed)instantaneously.ÃÆ'‚  This is a huge shock to the system.ÃÆ'‚  Your Accelerations are pretty high.ÃÆ'‚  Jogs do not do this as they limit Jerk.ÃÆ'‚  G1's do this but with two differences #1 they use different settings (TP settings).ÃÆ'‚  #2 they are rarely commanded at max feed rate (rapid rates).
> > > > > > ÃÆ'‚ 
> > > > > > Otherwise my standard answer is to capture the motion to a file and look to see exactly what is happening.ÃÆ'‚  You only need to catch one fault.
> > > > > > ÃÆ'‚ 
> > > > > > Regards
> > > > > > TK
> > > > > > ÃÆ'‚ 
> > > > > >
> > > > > > From: himykabibble <jagboy@>
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Sent: Sunday, February 12, 2012 8:26 AM
> > > > > > Subject: [DynoMotion] Jogging Problems
> > > > > >
> > > > > >
> > > > > > ÃÆ'‚ 
> > > > > > Tom,
> > > > > >
> > > > > > My one remaining problem is with jogging using the pendant. I'm sure this is a problem in my code, but so far I've had no luck finding it. I do have a few questions, just to validate what I'm doing.
> > > > > >
> > > > > > I have two different jog modes - one using MoveExp(), the other just using Jog(). AFAICT, the Jog() mode always works fine, even when doing rapid moved back and forth as fast as I can spin the MPG. But the MoveExp mode will generate frequent, random servo faults on all axes, sometimes at the very start, most often at the very end, of a move. The basic logic I use is similar to your MPGSmooth example, with some changes to accommodate the low resolution of my current MPG. The primary change is that I measure the time between "clicks" on the MPG, filter that, then apply a non-linear transform that increases the "step" size the faster you turn the MPG. This lets me go from moving in discrete 0.001" steps at the low end, to full 200IPM rapids at the top end, and actually gives me fine enough control to do very nice "manual" milling at almost any speed I want.
> > > > > >
> > > > > > I use MoveExp for doing the moves, and, for the MoveExp() mode, I use a final Move() when I detect it's time to stop. For the Jog() mode, I just use Jog(n, 0). I suspect my problem is in the stop code somewhere. I am currently not testing for motion to have fully stopped. So, it is possible I could, for example, be moving at high speed, decide it's time to stop, and issue a final Move(), then, very shortly after, issue a new MoveExp(), perhaps in the opposite direction. Is there anything you can think of I could be doing in the sequence of commands that could explain MoveExp or Move apparently violating the axis acceleration limit (I don't see what else could cause a servo fault)? All fours axes seem to be working 100% robustly under ALL other circumstances. I've run many hundreds of cycles of random moves of single and multiple axes doing G0s and G1s, and never had a single fault, so the problem does seem limited to the MoveExp pendant jog
> > functions.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
>